In the virtualized server environments, such as cloud computing environments, a virtualized server recovery (VSR) replication agent may be enabled to copy bit by bit every change on a customer disk to a VSR replication server (RS) where every customer partition is represented by a same sized partition on the RS side. Since replication in VSR for Linux root volume groups is working on a partition level, a replication server, which should be able to handle multiple volume groups from cloned systems on a customer side, may need to have unique UUIDs (Universal Unique IDentifier) for every physical volume managed by a LVM (logical volume manager) and volume group on the VSR side. The above mentioned UUIDs may be changed during customers' server boarding (i.e., new customer/user/server gets on board of a cloud computing environment) to the VSR by an automated process driven by the external company. A problem may occur at the moment a user is changing something in the LVM configuration relating to the volume group, such as, e.g., by a logical volume addition/removal/resize. If the VSR agent is replicating the original LVM information to the replication server, the VSR agent causes changed UUIDs to be reverted to the original UUIDs. In such situations, an administrator team has to change those parameters manually by a complicated process of finding affected replication pairs and running a full data comparison between a source server and replicated volumes, which is called “differential compare”.
However, if more than one server at the same time replicates the original LVM information, the replication server cannot determine which physical volume may belong to which volume group since the UUIDs are the same, which is causing conflicts for the operating system. and which may be fixed by taking action to stop the replication for one server, take the disks off related to the relevant server, replicate the second server again, change manually the UUIDs and re-attach the first server again using a UUID change procedure. When more servers replicate the original LVM information, such as in situations when a whole site (e.g., hundreds of servers) need to be re-replicated from the beginning, the volume group consistency restoration takes a lot of time due to the fact that every single server has to be fixed manually, one by one, while other servers are off-line, which leads to unacceptable off-line time, user complains, liability problems, and contractual complications in cloud computing environments.